Field
Embodiments of the present invention generally relate to the field of network security techniques. In particular, various embodiments relate to network security configuration file conversion with security policy auditing and optimization.
Description of the Related Art
Network security appliances, such as firewalls, are used for protecting networks from attacks, including, but not limited to, as malware, virus and Distributed Denial of Service (DDoS). An administrator may deploy a network security appliance at a border of a private network and configure a set of security policies in accordance with the needs of the private network. The network security appliance then checks network traffic going through the private network based on the security policies. An action, such as allow, deny or deep scanning, may be taken on the network traffic when the traffic triggers a security policy. The security policies of a large network can be very complicated because the security policies may be defined based on many parameters, including, but not limited to, the sources/destinations, protocols, applications of the network traffic, the roles of the users, schedules, domains and services. The security policies of a network security appliance may be stored within or backed up to a configuration file. As hundreds of security policies may be included in the configuration file, the security polices of the configuration file may be written/arranged in a script or language that is defined by the vendor of the network security appliance. Different vendors may have different scripts/languages for their respective configuration files. When an old network security appliance from one vendor is replaced by a new network security appliance of another vendor, the configuration file of the old network security appliance cannot be used by the new network security appliance because the syntax of the configuration file of the old network security appliance cannot be parsed by the new network security appliance. Usually, a converter from a network security appliance vendor or a third party may be used for converting a configuration file from a first language to a second language. However, the converter usually cannot fully convert a configuration file from one language to another as the languages of configuration files from different vendors may have different functions as well as different syntax to express functions of their respective network security appliances. For example, multiple functions of a network security appliance from a first vendor may be defined by one security policy in a first language of the first vendor. The same multiple functions may not be defined by one security policy in a second language of a second vendor. In this scenario, the converter may parse the security policy in the first language and convert it into multiple security policies in the second language to cover the multiple functions of the security policy. Here, the conversion integrity rate of input policy to output policy is 1:n instead of 1:1, and some policy fragments may be generated as a result. For a well-managed network security appliance, each security policy in the configuration file may have a note or comment to describe the function of the policy. The security policy together with such notes or comments may have been examined and approved by the network security administrators. The 1:n conversion and policy fragments may affect the maintenance of security policies and may result in the inadvertent creation of security vulnerabilities within the computer networks at issue.
The following are examples of security vulnerabilities that may be introduced as a result of a 1:n conversion:                1. Repeated policies, in which all 5-tuples of the security policies are the same. Here, the source IP addresses, the source ports, the destination Internet Protocol (IP) addresses, the destination ports and the actions of two policies are the same.        2. Conflicting policies, in which only the actions associated with 5-tuples of two or more security policies are different. Here, the source IP addresses, the source ports, the destination IP addresses and the destination ports of two or more policies are the same, but the actions defined by the two or more policies are different.        3. Encompassing policies, in which the IP addresses and/or the ports of a policy encompass IP addresses and/or ports of another policy while the actions are the same;        4. Mergeable policies, in which a tuple, e.g., the source IP addresses, the source ports, the destination IP addresses and/or the destination ports of two or more policies is different while the actions of the two or more policies are the same.        
Therefore, there is a need for a converter with security policy auditing and optimization to improve the integrity of security policy conversion.